Exploiting Top 10 API Vulnerabilities with Vulnerable API

Introduction

The OWASP API Security Top 10 outlines the most significant API security risks that developers and organizations need to be mindful of. This guide offers a walkthrough for exploiting these vulnerabilities using Vulnerable-API, a self-hosted Python application crafted to simulate OWASP API Top 10 scenarios through hands-on exercises.

Vulnerable-API, which can be found on GitHub at https://github.com/SNE-M23-SN/Vulnerable-API, its simple to set up by following the instructions provided in the README.md file. The guide includes steps on how to setup and exploit some of the vulnerabilities .
Note for the first part only 5 exploitation will be carried out.

Tools and Setup

To obtain a thorough grasp of the vulnerabilities you’re working with and properly exploit them, you’ll need a set of specific tools. Here’s a list of key tools you’ll need.

1. Docker

   Docker is a platform that has gained wide acceptance for containerization. It greatly simplifies the process of managing and deploying applications in containers, making it a vital tool for any developer.

   

• Install Docker: You can follow the detailed instructions provided on the Docker website to install Docker on your system. This will ensure that you have the latest and most secure version.

2. Burp Suite

   Burp Suite is a formidable tool in the realm of web application security testing. It offers a wide array of features, suitable for both manual and automated testing. It plays a vital role in intercepting and analyzing HTTP requests and responses, making it indispensable for security testing.

   

• Download Burp Suite: You can download the Burp Suite Community Edition for a comprehensive web application security testing toolkit.

3. Postman

   Postman has garnered popularity as a highly effective tool for testing APIs. It provides an intuitive user interface that allows you to easily send HTTP requests and closely examine the responses you receive. You have the option to use either the desktop application or the web version, depending on your preference.

   

• Desktop Version: You can download the Postman desktop application for a more robust and responsive interaction.
• Web Version: If you prefer a more lightweight approach, you can use the Postman for Web.

Postman and Burp Suite are both popular tools used for API testing, but they serve different purposes:

• Postman is primarily used for building, testing, and documenting APIs. It provides a user-friendly interface for creating API requests, managing environments, and collaborating with team members.

• Burp Suite is a comprehensive web application security testing platform. While it can be used for API testing, its main focus is on identifying vulnerabilities in web applications, including those exposed through APIs.

Combining Postman and Burp Suite in this guide can be beneficial for the following reasons:

1. Postman can be used to create and execute API requests, while Burp Suite can intercept and analyze the traffic to identify potential security issues.

2. Burp Suite can be used to test APIs for vulnerabilities like injection flaws, broken authentication, and security misconfigurations, which are covered in the OWASP API Security Top 10.

3. Using both tools together provides a more comprehensive approach to API testing, leveraging the strengths of each tool.

Docker is chosen as the containerization tool in this guide for several reasons:

1. Docker is the most popular and widely-used containerization platform, with a large and active community.

2. Docker provides a consistent and reproducible environment for running applications, making it easier to set up and deploy the vAPI application.

3. Docker simplifies the management of dependencies and ensures that the application runs consistently across different environments.

In addition to Docker, this guide will also use Docker Compose to define and manage the multi-container application. Docker Compose allows you to define the services, networks, and volumes required for the application in a single configuration file, making it easier to set up and manage the environment.

Setting Up Vulnerable-API

We can setup Vulnerable-API manually by installing directly on our system or use Docker to run a conterized app of the vulnerable-API. Using docker helps isolate the application from our host system.
in this Exercise we are going to use Docker we assume Docker is already installed.

1. Clone the Vulnerable-API Repository
   First, clone the Vulnerable-API repository from GitHub to your local machine:
   
   

2. Set Up the Docker image using the Build command

Run the following command

• Build the Docker image:
  ``` sudo docker build --tag vulnerable-api .``
• Run the Docker container:
  sudo docker run -it --rm -p8000:8000 vulnerable-api
• Open the API documentation in a web browser:
  open http://IP_OF_HOST:8000/docs
  

so now we have our environment set up lets see how we can possibly exploit some of the Vulnerabilities in the app such as:

1. Data Exposure by Logic Issues

Endpoint: /accounts/

Steps to Exploit:

Log in as a legitimate user to get a valid JWT token (see the data folder to get user).

Obtain JWT Token:

• Open Postman and create a new request.

• Set the method to POST and the URL to http://localhost:8000/token/.

• In the Body tab, select x-www-form-urlencoded and add the key-value pairs (Username and Password):

Use the token to access the /accounts/ endpoint.

Access /accounts/ Endpoint:

• Create another new request in Postman.

• Set the method to GET and the URL to http://localhost:8000/accounts/.

• In the Headers tab, add a new header:

• Observe if you can access other users’ accounts by manipulating the request using.

  http://localhost:8000/accounts/?username=another_user
  

From the previous screenshot we can see that modifying the with the usename parameter and another username does not expose any data as seen from the above screenshot. so we can conclude that this app is not vulnerable to Data Exposure by Logic issues

2. SQL Injection Attack

• Endpoint: /bank_codes/

  Prerequisites

• Basic knowledge of SQL and SQL Injection techniques

• API client (e.g., Postman)

• SQLMap tool for automated SQL Injection testing

  Steps to Exploit SQL Injection

  Step 1: Identify Injectable Parameter

  • Analyze the /bank_codes/ endpoint to identify where user input is used directly in SQL queries. In this case, the code parameter is used in the SQL query.
  • Using Postman create a new GET request Enter the URL for the /bank_codes/ endpoint http://localhost:8000/bank_codes/
  • from the image below we see that a bank code is returned after sending the request.Now lets try to add query paramenters.

• Using Postman create a new GET request Enter the URL for the /bank_codes/ endpoint with query parameters ?code=1’ OR ‘1’ =‘1’ ; - -
• http://localhost:8000/bank_codes/?code=1' OR '1' ='1' ; --
  
  upon submition of the request we get another bank code which shows our sql injection was successful. To get more from the database we will use sqlmap

To test the application with sqlmap we provide a target url with a customised query parameter
sqlmap --url "http://localhost:8000/bank_codes?code=1"

after executing the command with the GET parameter code we discover that it is injectable hence suitable for our task. the DBMS found is SQLite as seen above.To get all the database content we will make a database dump as shown below using.

sqlmap --url "http://localhost:8000/bank_codes?code=1" --dump

With all this we have been able to get details about the application database entries through sql injection. This demontrate that the application is vulnerable to SQL Injection Attacks

3. FIle Inclusion/Path Traversal

This vulnerability allows an attacker to access files or directories that are outside the web server’s root directory. Attackers can manipulate file paths to access unauthorized files.

Steps to exploit

• Identify the parameter used for file paths.
• Manipulate the parameter to traverse directories and read sensitive files.
• Send the payload via the /exchangerate/ endpoint.
• Observe the response to confirm file inclusion.

Get JWT Token: (As shown in Attack 1)

• Make a POST request to the /token/ endpoint with valid user credentials.

Send Malicious Payload:

• Make a GET request to the /exchangerate/?datestamp=…/…/…/…/etc/passwd endpoint with the JWT token as shown as shown on the image below.
  
  receiving the response from the image above indicates that the file inclusion/path traversal vulnerability was successfully exploited.

4. Server Side Template Injection

Server Side Template Injection (SSTI) is a serious vulnerability that occurs when an application allows user input to directly control or influence templates on the server-side. This can lead to arbitrary code execution and compromise the security of the application.

What is SSTI?

SSTI occurs when user-controllable data (typically via HTTP parameters or user inputs) is embedded within a template context on the server-side.
Templates are often used in web applications for rendering dynamic content, such as HTML pages, emails, or other text-based formats.

Steps to Exploit:

• Identify the parameter used in the template.
• Inject template syntax to execute arbitrary code

Inject Malicious Template: Make a GET request to the greeter endpoint with the following:

• Parameter used: name
• Parameter Value: {{ ‘<script>alert(“XSS”)</script>’ }}
  http://localhost:8000/greeter/?name={{ '<script>alert("XSS")</script>' }
  

After sending the request the server responds with a Hello {{ ‘<script>alert(“XSS”)</script>’ }} demonstrating that the injection was successful

Impact of SSTI:

• Allows attackers to execute arbitrary code on the server.
• Can lead to data exposure, server compromise, or even complete system takeover.

5. Dumping In-Memory Data

The “Dumping In-Memory Data” attack refers to the exploitation of vulnerabilities that allow an attacker to access and extract sensitive data directly from a web application’s memory space. This can be particularly damaging because the data stored in memory often includes session tokens, plaintext passwords, API keys, and other sensitive information used during the application’s runtime

Exploiting Dumping In-Memory Data

1. Identify Endpoints

Endpoints: /vulnapi/inmemory/usersdb
            /vulnapi/inmemory/accounts

These endpoints are designed to dump sensitive in-memory data, allowing unauthorized access to user and account information.

2. Steps to Exploit

• Access the Endpoints:

• Make a TRACE request to each of the endpoints separately using curl for example.

• Retrieve Sensitive Information using:
  curl -X TRACE http://localhost:8000/vulnapi/inmemory/accounts
curl -X TRACE http://localhost:8000/vulnapi/inmemory/usersdb

• Upon successful exploitation, you should receive a response containing the dumped data from users_db and accounts_db.
  

The successful exploition of the vulnerabilities in our intentionally vulnerable API can be significant and illustrates the potential risks associated with poor application security practices. some key impacts include:

Data Exposure:

Sensitive Information Leakage: Attackers can access usernames, email addresses, hashed passwords, plaintext passwords, and other personal details of users. This information can be exploited for identity theft, unauthorized access, or phishing attacks.

Conclusion

The successful exploitation of the vulnerabilities in our intentionally vulnerable API illustrates the potential risks associated with poor application security practices. Key impacts include data exposure, identity theft, unauthorized access, and more. Following best practices in application security is essential to protect sensitive information and maintain the integrity of web applications.